Method and nework for ensuring secure forwarding of messages

ABSTRACT

The method and network ensure secure forwarding of a message in a telecommunication network that has at least one first terminal and another terminal. The first terminal moves from a first address to a second address. A secure connection between the first address of the first terminal and the other terminal defining at least the addresses of the two terminals is established. When the first terminal moves from the first address to a second address, the connection is changed to be between the second address and to the other terminal by means of a request from the first terminal and preferably a reply back to the first terminal.

TECHNICAL FIELD

The method and network of the invention is intended to secure mobileconnections in telecommunication networks. Especially, it is meant forIPSec connections.

The invention provides a method for ensuring secure forwarding of amessage in a telecommunication network comprising at least one mobileterminal and another terminal, when the mobile terminal moves from afirst address to a second address and there is a secure connectionestablished between the first address of the mobile terminal and theother terminal, which secure connection defines at least the addressesof the two terminals. The invention also provides a network forperforming such a method.

TECHNICAL BACKGROUND

An internetwork is a collection of individual networks connected withintermediate networking devices and functions as a single large network.Different networks can be interconnected by routers and other networkingdevices to create an internetwork.

A local area network (LAN) is a data network that covers a relativelysmall geographic area. It typically connects workstations, personalcomputers, printers and other devices A wide area network (WAN) is adata communication network that covers a relatively broad geographicarea. Wide area networks (WANs) interconnect U-Ns across normaltelephone lines and, for instance, optical networks; therebyinterconnecting geographically disposed users.

There is a need to protect data and resources from disclosure, toguarantee the authenticity of data, and to protect systems from networkbased attacks. More in detail, there is a need for confidentiality(protecting the contents of data from being read), integrity (protectingthe data from being modified, which is a property that is independent ofconfidentiality), authentication (obtaining assurance about the actualsender of data), replay protection (guaranteeing that data is fresh, andnot a copy of previously sent data), identity protection (keeping theidentities of parties exchanging data secret from outsiders), highavailability, i.e. denial-of-service protection (ensuring that thesystem functions even when under attack) and access control. IPSec is atechnology providing most of these, but not all of them. (In particular,identity protection is not completely handled by IPSec, and neither isdenial-of-service protection.)

The IP security protocols (IPSec) provides the capability to securecommunications between arbitrary hosts, e.g. across a LAN, acrossprivate and public wide area networks (WANs) and across the internetIPSec can be used in different ways, such as for building secure virtualprivate networks, to gain a secure access to a company network, or tosecure communication with other organisations, ensuring authenticationand confidentiality and providing a key exchange mechanism. IPSecensures confidentiality integrity, authentication, replay protection,limited traffic flow confidentiality, limited identity protection, andaccess control based on authenticated identities. Even if someapplications already have built in security protocols, the use of IPSecfurther enhances the security.

IPSec can encrypt and/or authenticate traffic at IP level. Traffic goingin to a WAN is typically compressed and encrypted and traffic comingfrom a WAN is decrypted and decompressed. IPSec is defined by certaindocuments, which contain rules for the IPSec architecture. The documentsthat define IPSec, are, for the time being, the Request For Comments(RFC) series of the Internet Engineering Task Force (IETF), inparticular, RFCs 2401-2412.

Two protocols are used to provide security at the IP layer; anauthentication protocol designated by the header of the protocol,Authentication Header (AH), and a combined encryption/authenticationprotocol designated by the format of the packet for that protocol,Encapsulating Security Payload (ESP). AH and ESP are however similarprotocols, both operating by adding a protocol header. Both AH and ESPare vehicles for access control based on the distribution ofcryptographic keys and the management of traffic flows related to thesesecurity protocols.

Security association (SA) is a key concept in the authentication and theconfidentiality mechanisms for IP. A security association is a one-wayrelationship between a sender and a receiver that offers securityservices to the traffic carried on it if a secure two way relationshipis needed, then two security associations are required. If ESP and AHare combined, or if ESP and/or AH are applied more than once, the termSA bundle is used, meaning that two or more SAs are used. Thus, SAbundle refers to one or more SAs applied in sequence, e.g. by firstperforming an ESP protection, and then an AH protection. The SA bundleis the combination of all SAs used to secure a packet.

The term IPsec connection is used in what follows in place of an IPSecbundle of one or more security associations, or a pair of IPSecbundles—one bundle for each direction—of one or more securityassociations. This term thus covers both unidirectional andbidirectional traffic protection. There is no implication of symmetry ofthe directions, i.e., the algorithms and IPSec transforms used for eachdirection may be different.

A security association is uniquely identified by three parameters. Thefirst one, the Security Parameters Index (SPI), is a bit string assignedto this St The SPI is carried in AH and ESP headers to enable thereceiving system to select the SA under which a received packet will beprocessed. IP destination address is the second parameter, which is theaddress of the destination end point of the SA, which may be an end usersystem or a network system such as a firewall or a router. The thirdparameter, the security protocol identifier indicates whether theassociation is an AH or ESP security association.

In each IPSec implementation, there is a nominal security associationdata base (SADB) that defines the parameters associated with each SA. Asecurity association is normally defined by the following parameters.The Sequence Number Counter is a 32-bit value used to generate thesequence number field in AH or ESP-headers. The Sequence CounterOverflow is a flag indicating whether overflow of the sequence numbercounter should generate an auditable event and prevent furthertransmission of packets on this SA. An Anti-Replay Window is used todetermine whether an inbound AH or ESP packet is a replay. AHinformation involves information about the authentication algorithm,keys and related parameters being used with AH. ESP information involvesinformation of encryption and authentication algorithms, keys,initialisation vectors, and related parameters being used with IPSec.The sixth parameter, Lifetime of this Security Association, is atime-interval and/or byte-count after which a SA must be replaced with anew SA (and: new SPI) or terminated plus an indication of which of theseactions should occur. IPSec Protocol Mode is either tunnel or transportmode. Path MTU, which is an optional feature, defines the maximum sizeof a packet that can be transmitted without fragmentation.

Both AH and ESP support two modes used, transport and tunnel mode.

Transport mode provides protection primarily for upper layer protocolsand extends to the payload of an IP packet. Typically, transport mode isused for end-to-end communication between two hosts. Transport mode maybe used in conjunction with a tunnelling protocol (other that IPSectunnelling).

Tunnel mode provides protection to the entire IP packet and is generallyused for sending messages through more than two components, althoughtunnel mode may also be used for end-to-end communication between twohosts. Tunnel mode is often used when one or both ends of a SA is asecurity gateway, such as a firewall or a router that implements IPSec.With tunnel mode, a number of hosts on networks behind firewalls mayengage in secure communications without implementing IPSec. Theunprotected packets generated by such hosts are tunnelled throughexternal networks by tunnel mode SAs set up by the IPSec software in thefirewall or secure router at boundary of the local network.

To achieve this, after the AH or ESP fields are added to the IP packet,the entire packet plus security fields are treated as the payload of anew outer IP packet with a new outer IP header. The entire original, orinner, packet travels through a tunnel from one point of an IP networkto another no routers along the way are able to examine the inner IPpacket. Because the original packet is encapsulated, the new largerpacket may have totally different source and destination addresses,adding to the security. In other words, the first step in protecting thepacket using tunnel mode is to add a new IP header to the packet; thusthe “IP|payload” packet becomes “IP|IP|payload”. The next step is tosecure the packet using ESP and/or AH. In case of ESP, the resultingpacket is “IP|ESP|IP|payload”. The whole inner packet is covered by theESP and/or AH protection. AH also protects parts of the outer header, inaddition to the whole inner packet.

The IPSec tunnel mode operates e.g. in such a way that if a host on anetwork generates an IP packet with a destination address of anotherhost on another network, the packet is routed from the originating hostto a security gateway (SGW), firewall or other secure router at theboundary of the first network. The SGW or the like filters all outgoingpackets to determine the need for IPSec processing. If this packet fromthe first host to another host requires IPSec, the firewall performsIPSec processing and encapsulates the packet in an outer IP header. Thesource IP address of this outer IP header is this firewall and thedestination address may be a firewall that forms the boundary to theother local network. This packet is now routed to the other hostsfirewall with intermediate routers examining only the outer IP header.At the other host firewall, the outer IP header is stripped off and theinner packet is delivered to the other host.

ESP in tunnel mode encrypts and optionally authenticates the entireinner IP packet, including the inner IP header. AH in tunnel modeauthenticates the entire inner IP packet including the inner IP header,and selected portions of the outer IP header.

The key management portion of IPSec involves the determination anddistribution of secret keys. The default automated key managementprotocol for IPSec is referred to as ISAKMP/Oakley and consists of theOakley key determination protocol and Internet Security Association andKey Management Protocol (ISAKMP). Internet key exchange (IKE) is a newername for the ISAKMP/Oakley protocol. IKE is based on the Diffie-Hellmanalgorithm and supports RSA signature authentication among other modes.IKE is an extensible protocol, and allows future and vendor-specificfeatures to be added without compromising functionality.

IPSec has been designed to provide confidentiality, integrity, andreplay protection for IP packets. However, IPSec is intended to workwith static network topology, where hosts are fixed to certainsubnetworks. For instance, when an IPSec tunnel has been formed by usingInternet Key Exchange (IKE) protocol, the tunnel endpoints are fixed andremain constant If IPSec is used with a mobile host the IKE key exchangewill have to be redone from every new visited network. This isproblematic, because IKE key exchanges involve computationally expensiveDiffie-Hellman key exchange algorithm calculations and possibly RSAcalculations. Furthermore, the key exchange requires at least threeround trips (six messages) if using the IKE aggressive mode followed, byIKE quick mode, and nine messages if using IKE main mode followed by IKEquick mode. This may be a big problem in high latency networks, such asGeneral Packet Radio Service (GPRS) regardless of the computationalexpenses.

In this text, the term mobility and mobile terminal does not only meanphysical mobility, instead the term mobility is in the first hand meantmoving from one network to another, which can be performed by aphysically fixed terminal as well.

The problem with standard IPSec tunnel end points are that they arefixed. A SA is bound to a certain IP address, and if it is changed, theexisting IPSec SA becomes useless because it has been established byusing different endpoint addresses. The problem has been discussed inthe IETF standardisation forum, www.IETF.org, wherein an idea to supportmobility for IPSec ESP tunnels by means of signalling to update theaddress of one end after a movement was mentioned by Francis Dupont. Nosolutions have however been presented until this date.

The standard Mobile IP protocol provides a mobile terminal with a mobileconnection, and defines mechanisms for performing efficient handoversfrom one network to another. However, Mobile IP has severaldisadvantages. The security of Mobile IP is very limited. The mobilitysignalling messages are authenticated, but not encrypted, and user datatraffic is completely unprotected. Also, there is no key, exchangemechanism for establishing the cryptographic keys required forauthenticating the mobility signalling. Such keys need to be typicallydistributed manually. Finally, the current Mobile IP protocol does notdefine a method for working through Network Address Translation (NAT)devices.

A way to solve this problem is to use e.g. Mobile IP to handle themobility of the host, and use IPSec on top of the static IP addressprovided by the Mobile IP. Thus, the IPSec SAs are bound to staticaddresses, and the IPSec SAs can survive mobility of the host. However,this approach suffers from packet size overhead of both Mobile IP andIPSec tunnels, which can affect performance considerably when usinglinks with small throughput.

The documents that define IP in general are the RFC standards RFC 768,RFC 791, RFC 7933, RFC 826 and RFC 2460. RFC 2002, RFC 2003, RFC 2131,RFC 3115, MOBILE Ipv4 and IPv6, and DHCPV6 define Mobile IP, IP-IP andDHCP.

Prior art solutions in this technical area are presented in WO 01 39538,WO 00 41427, WO 01 24560, US 2001/009025 and EP 1 24 397.

In WO 01 39538, WO 00 41427, WO 01 24560 and EP 1 24 397, a secureconnection, which in the two first emntioned ones is an IPSec SAconnection, is transferred from one access point to another in ahand-over situation of a mobile terminal. US 2001/009025 generallypresents a secure communication method by means of an IP Sec SAconnection.

REFERENCES

The following is a list of useful references of standards mentioned.

IP in general, TCP and UDP:

[RFC768]

-   J. Postel, User Datagram Protocol, RFC 768, August 1980.    ftp://ftp.isi.edu/in-notes/rfc7688.txt    [RFC791]-   J. Postel, Internet Protocol, RFC 791, September 1981.    ftp://ftp.isi.edu/in-notes/rfc791.text    [RFC792]-   J. Postel, Internet Control Message Protocol, RFC 792,    September 1981. ftp://ftp.isi.edu/in-notes/rfc792.txt    [RFC793]-   J. Postel, Transmission Control Protocol, RFC 793, September 1981.    ftp://ftp.isi.edu/in-notes/rfc793.txt    [RFC826]-   D. C. Plummer, An Ethernet Address Resoluffon Protocol, RFC 826,    November 1982. ftp://ftp.isi.edu/in-notes/rfc826.txt    [RFC2460]-   S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)    Specification, RFC 2460, December 1998.    [RFC2002]-   C. Perkins, IP Mobility Support, RFC 2002, October 1996.    ftp://ftp.isi.edu/in-notes/rfc2002.txt    [RFC2003]-   C. Perkins, IP Encapsulation Within IP, RFC 2003, October 1996.    ftp://ftp.isi.edu/in-notes/rfc2003.txt    [RFC2131]-   R. Droms, Dynamic Host Configuration Protocol, RFC 2131, March 1997.    ftp://ftp.isi.edu/in-notes/rfc2131.txt    [RFC3115]-   G. Dommety, and K. Leung, Mobile IP Vendor/Organization-specific    Extensions, RFC 3115, April 2001.    ftp://ftp.isi.edu/in-notes/rfc3115.txt    [MOBILEIPv6]-   D. B. Johnson, C. Perkins, Mobility Support in IPv6, Work in    progress (Internet-Draft is available), July 2000.    [DHCPV6]-   J. Bound, M. Carney, C. Perking, R. Droms, Dynamic Host    Configuration Protocol for IPv6 (DHCPv6), Work in progress    (Internet-Draft is available), June 2001.    IPsec Standards:    [RFC2401]-   S. Kent, and R. Atkinson, Security Architecture for the Internet    Protocol, RFC 2401, November 1998.    ftp://ftp.isi.edu/in-notes/rfc2401.txt    [RFC2402]-   S. Kent, and R. Atkinson, IP Authentication Header, RFC 2402,    November. 1998. ftp://ftp.isi.edu/in-notes/rfc2402.txt    [RFC2403]-   C. Madson, R. Glenn, The Use of HMAC-MD596 within ESP and AH, RFC    2403, November 1998.    [RFC2404]-   C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 win ESP and AH, RFC    2404, November 1998.    [RFC2405]-   C. Madson, N. Doraswamy, The ESP DES-CBC Cipher Algorithm With    Explicit IV, RFC 2405, November 1998.    [RFC2406]-   S. Kent, and R. Atkinson, IP Encapsulating Security Payload (ESP),    RFC 2406, November 1998. ftp://ftp.isi.edu/in-notes/rfc2406.txt    [RFC2407]-   D. Piper, The internet IP Security Domain of Interpretation for    ISAKMP, RFC 2407, November 1998.    ftp://ftp.isi.edu/in-notes/rfc2407.txt    [RFC2408]-   D. Maughan, M. Schneider, M. Scheater, and J. Turner, Internet    Security Association and Key Management Protocol (ISAKMP), RFC 2408,    November 1998. ftp://ftp.isi.edu/in-notes/rfc2408.txt    [RFC2409]-   D. Harkins, and D. Carrel, The Internet Key Exchange (IKE), RFC    2409, November 1998. ftp://ftp.isi.edu/in-notes/rfc2409.txt    [RFC2410]-   R. Glenn, S. Kent, The NULL Encryption Algorithm and Its Use With    IPsec, RFC 2410, November 1998.    [RFC2411]-   R. Thayer, N. Doraswamy, R. Glenn, IP Security Document Roadmap, RFC    2411, November 1998.    [RFC2412]-   H. Orman, The OAKLEY Key Determination Protocol, RFC 2412, November    1998.    NAT:    [RFC2694]-   P. Srisuresh, G. Tsirtsis, P. Akkiraju, and A Heffeman, DNS    Extensions to Network Address Translators (DNS _(—) ALG), RFC 2694,    September 1999.    [RFC3022]-   P. Shisuresh, K. Egevang, Traditional IP Network Address Translator    (Traditional NAT), RFC 3022, January 2001    ftp://ftp.isi.edu/in-notes/rfc3022.txt

THE OBJECT OF THE INVENTION

The object of the invention is to ensure secure forwarding of messagesfrom and to mobile terminals by avoiding the problems of prior art.

SUMMARY OF THE INVENTION

The method and network of the invention is to ensure secure forwardingof a message in a telecommunication network, comprising at least onefirst terminal and another terminal. In the method, the first terminalmoves from a first address to a second address. A secure connectionbetween the first address of the first terminal and the other terminaldefining at least the addresses of the two terminals is established. Thefirst terminal moves from the first address to a second address. Theconnection is changed to be between the second address and the otherterminal by means of a request from the first terminal and preferably, areply back to the first terminal.

In the invention, the first terminal is movable from one network toanother. Such a terminal can physically be a mobile terminal or a fixedterminal.

The secure connection is an IPSec connection established by forming oneor more Security Associations (SAs) using the IPSec protocols. Therequest and/or the reply message can be protected e.g. by IPSecencryption and/or authentication, possibly using the same IPSec SA thatis used for traffic protection purposes.

In general, registration request and registration reply are Mobile IPterms while the invention is not bound to Mobile IP. In the invention,the terms request and reply are used in the generic sense, and may ormay not be related to Mobile IP.

The method of the invention can be used in different kinds of networks.If the first terminal and the other terminal form an end-to-endconnection, the secure connection may be an IPSec tunnel mode ortransport mode connection. Furthermore, one of or both of the firstterminal and the other terminal can be a security gateway protecting oneor more computers, whereby IPSec tunnel mode, or IPSec transport modetogether with a tunnelling protocol (such as Layer 2 TunnellingProtocol, L2TP), is used for the secure connection between the firstterminal and the other terminal.

If both terminals are mobile, a special solution is required for thesituation when both terminals move simultaneously in case of a so called“double jump” situation. This solution can be implemented e.g. by usinga centralised registry of current locations of hosts, although othersolutions exist for the problem. However, the “changeable” IPSec tunnelor transport mode SAs of the invention could be used in that case, too.

The applicant has solved the above problems of prior art by defining asignalling mechanism that allows an existing IPSec security association,that is, the symmetric encryption and authentication algorithms used forpacket processing, along with their keys and other parameters, to bemoved from one network to another. To be more precise, an existing IPSectunnel endpoint can be moved in the invention from one point ofattachment to another. For instance, an IPSec tunnel established betweenaddresses A and X tunnel can be changed by using the defined signallingto be between addresses B and X using only a single round trip forsignalling (2 messages), or half a round trip (1 message, if a replymessage is not used) for signalling. The solution requires minimalcomputational overhead compared to Diffie-Helman or strongauthentication calculations.

The signalling mechanism is preferably similar to the one in Mobile IP,i.e. a registration request (RREQ) is sent to the other end of the SAfollowed by a registration reply (RREP) back to the sender of the RREQmessage, both of which are extensible for future features and optionalattributes. The RREQ/RREP message pair is sent from the new network, andonce properly authenticated, the sender IPSec tunnel endpoint is updatedfrom the old network to the now network.

In case the security association used for protecting user traffic isalso used for signalling purposes, the reception of the RREQ message bythe other end of the SA requires a change in a normal IPSecimplementation to accept a packet that appears to belong to a certainIPSec tunnel, but comes from a wrong address (i.e. the tunnel iscurrently between A and X, and the RREQ comes from address B). This isonly necessary for the RREQ message. Such an implementation is providedby the invention; it is necessary to modify IPSec if IPSec is used forthe RREQ/RREP signalling. In that case, it is required specifically forprocessing of the RREQ and RREP messages, if the reply message is to beused.

The request message may-update a set of security associations, forinstance, a single security association, a security association bundle,an IPSec connection, a group of IPSec connections, or any combinationsof these. In practice, it is useful to update either a single IPSecconnection or a group of IPSec connections. The latter may be importantif separate IPSec connections are used for different kinds of traffic. Asingle request message can then update all (or a certain set) of suchconnections to a new address, instead of requiring separate requests foreach IPSec connection. In the following, the case of updating a singleIPSec connection is discussed, without limiting the invention to thisbehaviour.

Another method of performing the signalling is to use a separateprotocol. The protocol should preferably provide encryption and/orauthentication of the signalling messages. The IKE protocol already hasmessages defined for e.g. deleting IPSec SAs. One method of providingthe necessary signalling would be by adding a new IKE notificationmessage type that requests a change in an existing IPSec SA Such amessage should provide its own encryption and/or authentication to avoidrequiring an IKE connection set up from the new address, which wouldrequire extra messaging.

IP version 4 (IPv4) is the currently widely deployed Internet Protocolversion. Its major disadvantage is the small number of unique, public IPaddresses. IP version 6 (IPv6) has a much larger address space, whichfixes the most important IPv4 problem known today. IPv6 also changessome other things in the Internet Protocol, for example, howfragmentation of packets is done, but these changes are quite small.Most protocols have separate definitions on how they are used within theIPv4 and the IPv6 context.

For instance, there are separate versions of IPSec and Mobile IP for usewith IPv4 and IPv6. However, such modifications to protocols are quitesmall, and do not usually change the essentials of the protocolssignificantly. The invention can be applied to both IPv4 and IPv6.

In the following, the invention is further described by means of figuresand some examples. The intention is not to restrict the invention to thedetails of the following description or to the details of protocols suchas the IPSec and IKE protocols which might be changed in the future.

FIGURES

FIG. 1 illustrates an example of a telecommunication network to be usedin the invention.

FIG. 2 illustrates a second example of a telecommunication network to beused in the invention.

FIG. 3 illustrates a third example of a telecommunication network to beused in the invention.

FIG. 4 describes the prior art solution to enable mobility for IPSecconnections.

FIG. 5 describes the method of the invention to enable mobility forIPSec connections.

DETAILED DESCRIPTION

FIG. 1 illustrates an example of a telecommunication network to be usedin the invention. Thus, in FIG. 1, computer 1 may be a client computerand computer 2 a destination computer, to which the secure messages aresent in the invention by means of an IPSec tunnel established betweencomputer 1 and computer 2. Computer 2 might be a security gateway for athird computer 3. Then, the messages sent from computer 2 to computer 3are sent in plaintext. The security gateway can be a common securitygateway for e.g. a company LAN, whereby there are several computers inthe LAN protected by computer 2. The other protected computers are notshown in FIG. 1, but naturally, the invention covers also such networks.

The network of FIG. 2 otherwise corresponds to that of FIG. 1, but inFIG. 2 also computer 1 is a security gateway, e.g. for computer 4. Alsohere, the security gateway 1 can be a common security gateway for e.g. acompany LAN, whereby there are several computers in the LAN protected bycomputer 1. The other protected computers are not shown in FIG. 2 Butnaturally, the invention covers also such networks. The messages betweensecurity gateway 1 and the computers it protects are sent in plaintextas the IPSec tunnel only exist between computers 1 and 2.

The network of FIG. 3 is a network wherein the IPSec messages are sentbetween an end-to-end connection between two computers 1, 2 only wherebyIPSec transport mode can be used instead of tunnel mode.

FIG. 4 describes the prior art solution to enable mobility for IPSecconnections. As a diagram, this is the standard IPSec procedure whenestablishing a tunnel between addresses A and X, and then B and X.

The protocol begins with the IKE main mode requiring 6 messages intotal, see steps 1 a-6 a in FIG. 4. The protocol involves strong userauthentication, policy negotiation and the use of the Diffie-Hellmanalgorithm. Any other IKE phase 1 mode might of course be used as analternative. Another approach to minimise the number of messageexchanges would be to avoid IKE phase 1 and perform only the IKE quickmode (3 messages). However, IKE phase 1 is associated with IP addresses(along with other identifying information). A modified implementationmight ignore IP addresses when processing IKE messages, and thus be ableto maintain IKE phase 1 state between connection points.

The protocol then continues with IKE quick mode requiring 3 messages intotal (steps 7 a-9 a in FIG. 4). Quick mode includes IPSec policynegotiation and optionally the use of the Diffie-Helman algorithm. Analternative IKE phase 2 exchange could of course be used instead ofquick mode.

At this point the tunnel has been established between addresses A and X.9 messages have been used along with the computational expense (eachDiffie-Hellman computation may take hundreds of milliseconds, forinstance, depending on the host), also the roundtrip times beingconsiderable (9/2=4.5 roundtrips, with a roundtrip time of 500 ms thisis 2.25 seconds for latency alone).

The movement of the mobile terminal to address B causes fullre-negotiation and again IKE main mode requires 6 messages in total(steps 1 b-6 b in FIG. 4), strong user authentication, policynegotiation, and optionally the use of the Diffie-Helman algorithm.

The use of the protocol continues with IKE quick mode requiring 3messages total (steps 7 b-9 b).

The tunnel between addresses B and X is now complete.

FIG. 5 describes the method of the invention. To establish the tunnelbeen address A and host X, IKE main mode is again used requiring 6messages in total (steps 1 a-6 a in FIG. 5) as in FIG. 4 includingstrong user authentication, policy negotiation and the use of theDiffie-Hellman algorithm.

Then IKE quick mode is again used requiring 3 messages in total (steps 7a-9 in FIG. 5). The quick mode includes IPSec policy negotiation, andoptionally the use of the Diffie-Hellman algorithm.

Again, IKE main mode may be replaced by any other IKE phase I mode, andIKE quick mode by any other IKE phase 2 mode.

At this point the tunnel has been established between addresses A and X.9 messages have been used along with the computational expense.

In the invention, movement to address B requires only a single roundtrip, when using registration request messages to be sent from themobile terminal, when it moves from address A to address B. In signal 10a of FIG. 5, which is sent from the mobile terminal to the other end ofthe established IPSec tunnel when it has moved to address B, a requestfor registration (RREQ) of the new address is sent. Preferably, a replymessage (RREP) is sent (step 11 a) from the host to confirm the addresschange. Both signals 10 a and 11 a can be encrypted and/orauthenticated. The encryption and/or authentication is preferablyperformed by using IPSec, in which case it is preferable to use the sameIPSec SA for protecting both data and registration traffic.

11 a is optional in the invention. The preferable encryption method isIPSec, preferably with the modified reception processing describedpreviously. However, the exact method of signalling is not important,the essence is to carry over the IPSec SA to the new connection point.

The SA that existed between addresses A and X has now been changed to bebetween addresses B and X and is now complete. The next time the mobileterminal sends a message, host 2 in FIG. 1-3 is able to properly handleIPSec packets that come from address B and vice versa. Traffic can nowflow inside the tunnel as normal with IPSec.

Any further movement from network to another can be accomplished with asimilar exchange of signalling message(s). The IPSec SA does not need tobe re-established until the lifetime of the SA has been exhausted.

The invention requires half a roundtrip if only a request message isused without a reply, and one roundtrip of the reply message is used.

The example describes the tunnel mode of IPSec, but transport mode canalso be used. IPSec transport mode connections in examples can bereplaced with IPSec tunnel mode connections and vice versa. IPSectransport mode combined with an external tunnelling protocol, such asthe Layer 2 Tunnelling Protocol (L2TP), is a replacement for IPSectunnel mode with regards to functionality.

The implementation may optimise the start of traffic flows with regardto message 10 a (and optionally 11 a); e.g. after sending 10 a, theclient may directly send IPSec-protected traffic. This essentially makesthe handover latency zero, although it requires more complicatedprocessing if the message 10 a is lost while being delivered. However,the essential part of the invention is that it is possible to make theinvention provide essentially zero-latency handover for client-to-servertraffic, and half a roundtrip latency for server-to client traffic.

Different network topologies can, of course, be used in the invention.For instance in FIG. 1, the connection between hosts 2 and 3 may useIPSec transport or tunnel mode, instead of being plaintext, etc.

1. A method for ensuring secure forwarding of a message in atelecommunication network, having at least one mobile terminal andanother terminal, the method comprising: a) establishing a secureconnection between a first address of the mobile terminal and the otherterminal, the secure connection defined by at least the addresses of thetwo terminals, b) the mobile terminal moving from the first address to asecond address, and c) changing the connection to be defined between thesecond address and the other terminal by means of a request message fromthe mobile terminal to the other terminal to change the address in thedefinition of the secure connection to the second address.
 2. The methodof claim 1, characterized in that, the secure connection is establishedin step a) by forming a Security Association (SA) using the IPSecprotocols.
 3. The method of claim 1, characterized in that in step c) areply back to the mobile terminal is sent from the other terminal afterthe request from the mobile terminal to change the address.
 4. Themethod of claim 1, characterized in that the registration request and/orthe reply message is encrypted and/or authenticated by using the same SAalready established.
 5. The method of claim 1, characterized in that thechange of addresses in the secure connection as a result of the requestmessage is performed by means of a central register of current addressof the terminals belonging to the network.
 6. The method of claim 1wherein the method further comprises providing a telecommunicationnetwork that has at least one mobile terminal and another terminal and asecure connection defined between a first address of the mobile terminaland the other terminal, characterized by means for changing theconnection to be defined between a second address of the mobile terminaland the other terminal.
 7. The method of claim 6, characterized in thatthe mobile terminal and the other terminal forms an end-to-endconnection whereby the secure connection is an IPSec transportconnection or IPSec tunnel connection.
 8. The method of claim 6,characterized in that one of or both of the mobile terminal and theother terminal is a security gateway protecting one or more computers,whereby IPSec tunnel mode or IPSec together with a tunneling protocol isused for the secure connection between the mobile terminal and the otherterminal.
 9. The method of claim 6, characterized in that both terminalsare mobile terminals.
 10. The method of claim 9, wherein the methodfurther comprises providing a central register of current locations ofthe terminals belonging to the network.